Test Results

2 347 tests  +7   2 347 ✅ +7   27m 36s ⏱️ +31s
  145 suites ±0       0 💤 ±0 
    7 files   ±0       0 ❌ ±0 

Results for commit bf9e212. ± Comparison against base commit 34d7c4e.

♻️ This comment has been updated with latest results.

I wouldn't use the IP alone as the unique identifier to map the open sockets (what happens when users behind NAT are sending requests?).
A combination of the real IP (extracted from X-Forwarded-For) and user-agent is adviced.

I wouldn't use the IP alone as the unique identifier to map the open sockets (what happens when users behind NAT are sending requests?). A combination of the real IP (extracted from X-Forwarded-For) and user-agent is adviced.

agreed and i would take it a step further, allow a special header to change the rate, and we force set this header on our nginx, because otherwise you have to manage special rate limits within the consumer

@nimrod-teich , @omerlavanet

I've added a header to rate limit. functionality is quite the same as the flag just here we can control it from ngnix instead of directly in process

Header name:
WebSocketRateLimitHeader = "x-lava-rate-limit"

Example use:
-H "x-lava-rate-limit: 10" (will result in rate limit of 10 requests per second)